This present invention relates generally to electronic communications and, more particularly, to a system and method for enabling users to migrate from the legacy SMTP protocol to an alternative email protocol, e.g., Bitmessage protocol.
Following the widespread adoption of the Internet, electronic mail is now a widely used method for communicating written information, used by billions globally. The protocol generally used by email software and systems to deliver email messages from senders to recipients through a packet-switched network is known as SMTP (Simple Mail Transport Protocol). The specification for SMTP was originally described in a publication known as RFC821 in 1982.
Impressively, now more than 30 years later, SMTP largely as defined in RFC821, is still widely used by email software and systems as the standard protocol for transporting email. However, while ahead of its time in 1982, SMTP has a number of inherent limitations which hinder its usability in today's world.
First and foremost, the widespread problem of junk email (known as ‘spam’) and consequently the use of spam filters to combat spam, have resulted in SMTP being unreliable. Spam filters are known to routinely flag legitimate messages as spam erroneously, resulting in these messages not being delivered to their intended recipients, many times unbeknownst to both the senders and the recipients of these messages. Many users feel that SMTP is unreliable because of this problem, and it is not uncommon for people in the technical community to express that SMTP is now ‘broken’ for this reason.
Another limitation of SMTP is that SMTP lacks a built-in method for authenticating the sender of a message. Because of this limitation, malicious senders are able to construct email messages appearing to originate from senders other than themselves. This technique, known as ‘spoofing’, is often exploited by spammers when sending large numbers of unsolicited and often malicious ‘phishing’ email messages.
Another limitation of SMTP is that it lacks built-in methods for enabling end-to-end encryption of messages, and for digital signing of messages. Another limitation of SMTP is that it lacks built-in methods for enabling a sender to track the delivery of a message through the internet, and confirm the receipt of a message by the recipient. Another limitation of SMTP is that users of hosted email services (such as Yahoo Mail, Gmail, Comcast, etc.) cannot easily migrate to another email service without changing their email address, because SMTP email addresses are coupled to domains.
As a result, alternative email transport protocols have been developed such as IM200 which is a “push” email protocol proposed by D. J. Bernstein in 2000 (see http://cr.yp.to/im2000.html and http://en.wikipedia.org/wiki/Internet Mail 2000). Another alternative is Stubmail, a variant of IM2000 developed by Meng Weng Wong and Julian Haight. Wong is the founder of POBox.com (one of the first hosted email services) and is also the creator of the Sender Policy Framework (SPF) protocol used for spam control. Haight is the founder of SpamCop.net, which is now owed by Cisco. (See:http://www.circleid.com/posts/hypertext_mail_protocol_aka_stub_emaill/, http://www.youtube.com/watch?v=Kp79SZaKcLg). Additional alternatives include AMTP (seehttp://amtp.bw.org/) and XMPP (see https://singpolyma.net/2007/07/replacing-smtp-with-xmpp/).
By way of example only, in 2012, an alternative protocol for a Peer-to-Peer Message Authentication and Delivery System, named ‘Bitmessage’ was proposed and released to the public under the MIT open source license. The protocol is described at the website www.bitmessage.org, and in a whitepaper by its creator, Jonathan Warren, at https://bitmessage.org/bitmessage.pdf.
As can be seen in the whitepaper, Bitmessage is a decentralized peer-to-peer messaging protocol. The contents of messages, as well as non-content ‘metadata’, are encrypted by the system from end-to-end, without the need for users to exchange encryption keys and without the need for certificates or trusted authorities. Messages are digitally signed by their senders, the protocol prevents spoofing of senders' addresses, and the protocol includes built-in methods for tracking and delivery confirmation. The system also includes a built-in method for controlling spam and users' addresses are not coupled to domains.
For all of the above reasons, the Bitmessage protocol is likely to be seen as superior to the SMTP protocol by many users, and hence many users are likely to be inclined to migrate to Bitmessage. However, migration from SMTP to Bitmessage is complicated by the fact that the two protocols are disparate of one another. Mature, feature-rich desktop mail clients, mobile mail clients, and webmail clients used to send and receive SMTP messages cannot readily be used to send and receive Bitmessage messages. The programs currently available for Bitmessage support only basic functionality and lack many of the tools and features that users have come to expect for managing messages. The fact that the two protocols are independent of one another also presents the user with cumbersome burden of having to operate two programs for messaging—one for SMTP (for communicating with associates who have not yet migrated to Bitmessage) and one for Bitmessage (for communicating with associates who have migrated to Bitmessage). Also, there is currently no directory in place for users or systems to determine if another party is setup for Bitmessage, and if so, what their Bitmessage address is given their SMTP addresses.
Thus, there remains a need for a system and method for SMTP and alternative email protocol interoperability.
All references cited herein are incorporated herein by reference in their entireties.